Due to the growing complexity of software solutions, software lifecycle management has become a critical task. The number of requirements associated with the software lifecycle management is increasing. This is especially true with respect to the development and maintenance of large enterprise computer systems. The modern enterprise computer systems run software applications that are built from a number of separate, sometimes independent, software components or modules. Thus, the deployment of a software application in an enterprise computer system involves installation and integration of a number of smaller software modules. At the same time, the maintenance of enterprise computer systems has to comply with tight operational requirements to ensure minimum downtime, high availability and cost efficiency. Accordingly, the lifecycle of every software module in the computer system is managed individually to retain the operability of the rest of the software components, if possible.
The existing enterprise computer systems are developed based on variety of architecture models. Traditional client-server computer systems employ a two-tiered architecture model, such as model 100 illustrated in FIG. 1A. One or more software applications 106 are executed on client 102 of the two-tiered architecture model 100. Application 106 is developed as a monolithic set of program code that includes a graphical user interface (GUI) component, presentation logic, business logic, etc.
Typically, “business logic” component of a software application represents the core functionality of the application, i.e., the rules governing the underlying process or services provided by this application. Whereas, a “presentation logic” component of a software application describes the specific manner in which the results of business logic processing are formatted and presented to the user.
Furthermore, application 106 has a network interface that enables client 102 to communicate with one or more servers 104 over network 110. Network 110 could be dedicated to connecting client 102 with server 104 within local area network (LAN) or wide area network (WAN). Alternatively, network 110 could be operable for connecting a group of computer systems within an intranet or Internet environment. Finally, network 110 could apply any of the existing network communication protocols, including transmission control protocol/internet protocol (TCP/IP).
Client 102 represents one of the tiers of the two-tier computer system architecture model. Client 102 provides an environment for executing application 106. Server 104 represents the other tier. Database 108 is maintained on server 104 to provide storage for application 106. Database 108 may store various types of business and system data depending on the functionality of application 106. For example, on database 108, application 106 could save, extract and process data for customers, inventory records, transaction logs, etc. Furthermore, database 108 may hold source code files of the software modules on application 106. Database 108 may also include data access logic used by the business logic of application 106 to store and retrieve data.
The two-tier architecture model for building computer systems can be effective but has certain limitations. These limitations become apparent when employed within large enterprise computer systems. For example, even with the aid of automated administration tools, the lifecycle management of two-tiered applications on a large number of different clients is a difficult task. Moreover, the tightly integrated business logic, presentation logic and user interface logic make the program code of such applications very complex, hard to maintain, and prone to errors. For example, a change to the user interface would require changes in business logic and presentation logic, and vice versa.
In the enterprise world, the established business rules change dynamically due to factors such as changes in statutory requirements, market developments, etc. Consequently, there are frequent requirements to change the existing software applications or install new software applications that provide certain enterprise services or that support specific business processes. Therefore, a more flexible architecture for building computer systems is appropriate.
To overcome the limitations associated with the two-tiered client-server architecture model, a multi-tiered architecture model for building computer systems has been developed, as illustrated in FIG. 1B. In a computer system with multi-tiered architecture, the presentation logic and the business logic are separated from each other and from the user interface. User interface 122 in client 132 is connected to presentation layer 124 via network 110. Presentation layer 124 is responsible for the definition and execution of the presentation logic and could be implemented on separate presentation server 134. Presentation layer 124 communicates with business layer 126 that could be implemented on business layer server 136. Database 128 provides storage on database server 138 for data relevant to the application including, user interface 122, presentation layer 124 and business layer 126. Presentation server 134, business layer server 136 and database server 138 could be implemented into one or more dedicated physical servers connected from client 132 via physical network 110.
The separation between the logic components and the user interface provides more flexible and scalable architecture for building computer systems, compared to the two-tiered model. For example, if business rules change, only the business logic implemented in business layer 126 could be changed to a new version without touching the program code on the rest of the levels. In another example, presentation layer 124 may provide support for a variety of third party user interfaces 122, e.g., popular browsers such as Internet Explorer™ or Mozilla Firefox™.
The multi-tiered architecture model illustrated in FIG. 1B may be implemented using a variety of different software technologies at each layer or tier, including Microsoft.NET™ technology by Microsoft Corporation, Advanced Business Application Programming (ABAP) technology by SAP AG, etc. One of the most popular software technologies for developing multi-tiered software applications is Java Enterprise Edition™ (Java EE) technology initially introduced by Sun Microsystems Inc. Java EE technology has been further co-developed by many other software vendors, and described in a special set of documentation that is referred to as Java EE Specification in this document. Due to its popularity and extensive use, Java EE Specification is publicly recognized as a standard. Therefore, different software developers could build applications compliant with Java EE Specification, and these applications could be executed on computer systems that are compliant with Java EE Specification, e.g., those that provide Java EE environment.
FIG. 1C illustrates an exemplary Java EE environment, in which core business logic of a software application is handled by Enterprise JavaBean™ (EJB) software components. EJB container 148 provides runtime environment for the EJB components within Java EE engine 142. The presentation layer is responsible for generating servlets and Java ServerPage™ (JSP) software components. Web container 146 provides runtime environment for JSP components within Java EE engine 142. The JSP components could be accessible with different types of popular Internet browsers at client 132 via network 110 and via Web server 144. Generally, Java EE engine 142 is an environment provided by an application server built according to Java EE Specification where software applications built with numerous integrated software modules are executed, including EJB components and JSP components. Database 128 stores relevant application and system data.
As enterprise application development projects grow larger and more diverse, deployment and maintenance of applications becomes increasingly important. For example, it is useful to have software lifecycle management involving a variety of container services, application programming interfaces (API), transaction management modules, notification systems, resource pooling, and security policy providers. Therefore, software vendors develop deployment tools to ensure such means of lifecycle management of the software applications and their components such as software modules.
In this document, the term “deploy tool” refers to administrative software application operable to deploying software application components to one or more destination computer systems, such as application server or cluster of application servers running on one or more physical computer servers. There are various requirements for deployment of software applications on particular application servers. These requirements depend on the software technology upon which the application server is built. Respectively, deployment tools may have to comply with the requirements of a certain application server software technology specification. For example, to deploy software applications on Java EE application server, a deployment tool may have to comply with the deployment requirements established in Java EE Specification.
FIG. 2 illustrates computer system 200 with an exemplary implementation of deploy tool 203 that converts various source code files 202 stored in repository 201 in an format that is appropriate for deployment on application server 213. For ease of understanding, FIG. 2 is drawn to comply with Java EE Specification providing component based object oriented environment for running software applications. However, the technique described herein is equally applicable to other environments. An application may include a number of modules operable for various functionalities. For instance, an application may include a number of software modules that perform backend business logic. Another application may consist of software modules that provide some form of Web interface, e.g., a Web application. Source code files 202 within repository 201 may include business logic source code to build or modify business logic components (e.g., EJBs in the case of Java EE environment) and Web application source code to build or modify Web application components (e.g., JSPs in the case of Java EE environment).
In the example illustrated with FIG. 2, various source code files 202 of modules of an application are passed to archive builder 204. Archive builder 204 creates two separate types of archive files. The first type of archive files are with extension “.jar” to indicate Java™ archive (JAR) files that contain business logic software modules. The second type of archive files are with extension “.war” to indicate Web archive (WAR) files that contain World Wide Web (Web) application software modules. JAR files 208 and WAR files 209 are then combined into an enterprise archive (EAR) file 206 by assembler 205. An archive file is a file that contains other files, e.g., file entries. The file entries in an archive file could be distributed within a directory structure.
Deployer 211 receives EAR file 206, analyzes its content, and sends the various pieces to their appropriate destinations. In the simplified illustration of FIG. 2, the content of JAR files 208 is sent to EJB container 215, and the content of WAR files 209 is sent to Web container 216 of application server 213. Application server 213 is assumed to have base environment 214 that provides a set of services 220. Containers 215 and 216 themselves can be viewed as subordinate environments of base environment 214, each having additional layer of services 219, according to Java EE Specification. Additionally, different vendors could introduce containers other than those described by Java EE Specification to provide runtime environment for various other modules of a software application.
FIG. 2 depicts exemplary contents of EAR file 206. Apart from the software components within JAR files 208 and WAR files 209, EAR file 206 also includes application deployment descriptor (DD) 207 (e.g., file “application.xml”, according to Java EE Specification). Furthermore, WAR file 209 includes module DD 210 (e.g., Web application DD as file “Web.xml”). The role of deployment descriptors 207 and 210 is to provide configuration metadata for the software components in JAR files 208 and WAR files 209. Version 5 of Java EE Specification introduces annotations as an additional way to provide configuration metadata. The deployment of software modules requires detecting the modules within the archive files based on the contents of the archive file entries, including the configuration metadata.
The Java EE compliant software applications are deployed on Java EE compliant application servers with the help of a compatible deploy tool. The compatibility of a deploy tool, either vendor specific (e.g., proprietary) or standardized (e.g., publicly recognized), could be ensured by adding a plug-in component. Such plug-in component provides functionality that is required by a deploy tool in order to follow a specific software deployment process. In FIG. 2, for instance, deployer 211 could be a plug-in component to a third party deploy tool 203.
The vendors of application servers have to provide reliable and efficient deploy framework for installation and integration of software components. An application server developed by an independent vendor could comply with an established application server specification, but in addition, could include features that are not included in the specification. Accordingly, deploy framework of such an application server has to ensure compliance with deployment requirements of the adopted technology specification, and with the features that are not part of the specification. Based on the specified deployment requirements, and the additional features, different application server vendors provide various proprietary deployment solutions.